1. Field of the Invention
The invention relates to integrating Java-based dialogs with native dialogs in an application program and, more particularly, to resolving inadequacies of a native interface.
2. Description of the Related Art
In the pre-Java programming paradigm, an application program was typically written in a high-level programming language, such as C, C++, or Visual Basic. Before compiling the program, or converting it into a machine-readable format, the application developer was forced to decide the environment in which the application was to be used, known commonly as a platform. The platform is made up both of the CPU that runs the application software and the operating system upon which the application software is loaded. A platform-specific compiler was then selected to convert the high-level program into a binary file suitable for that platform to run the program.
Unfortunately, the output of these compilers was usually understood only by the target platform. So, even though the application was written using a portable, high-level source code, with the goal of platform independence, each compiler outputted platform-specific code. The end result, for most application developers, was that a decision about which platform was being supported had to be made before any code was written.
Then, a new programming language, Java, emerged, along with a new programming paradigm. Java is a programming language, developed in the 1990s by Sun Microsystems of Palo Alto, Calif. A program written in Java compiles to a file, known as a bytecode file. A bytecode file can run wherever a Java virtual machine resides; thus, the bytecode is not specific to any physical machine. Sun describes the Java virtual machine, or JVM, as an abstract machine or xe2x80x9csoftxe2x80x9d computer that can be implemented in either hardware or software, to reside on top of existing platforms.
Unlike compilers under the old paradigm, there is only one specification for the Java Virtual Machine. (Virtual machines are available from a great many vendors, including Sun, Netscape, IBM, etc. Those virtual machines which adhere to the original virtual machine specification are known as xe2x80x9cpure Javaxe2x80x9d VMs.) So, an application developer who uses the Java language can rest assured that the application runs on any Java-capable platform: that is, any platform upon which a Java virtual machine resides. (Slight differences may appear on the GUI, but these are visual, not functional, differences.) This portability makes Java particularly suited for use on the Internet.
The Java virtual machine is also flexible in how it is implemented. The Java virtual machine may be installed onto a machine as a distinct application program, may be embedded within the operating system that resides upon the machine, or may be part of an application program which uses a Java virtual machine. Many browsers and operating systems today are touted as xe2x80x9cJava-capablexe2x80x9d because they include a Java virtual machine.
The presence of this new programming paradigm presents both new opportunities and new concerns. For one thing, an enormous installed base of application programs, written in other high-level programming languages under the old paradigm, are still being used and maintained. However most Java-aware developers understandably want to develop new applications, or add functionality to existing applications, using Java. The xe2x80x9cwrite-once, run anywherexe2x80x9d promise of Java bytecode eliminates the need for the developer to rewrite an application for each possible platform. Thus, it may be sensible for developers to write all new code in Java where possible.
When developing new applications, it may be possible to write the application entirely in Java. For adding new functionality to an existing application, however, some mechanism for allowing newly developed, Java-based bytecode to interact with the legacy, or native, application software, is required.
A software development kit, known as the Java Development Kit, or JDK, provides several programs to assist Java developers. The Java Virtual Machine, described above, is one of its many components. Additionally, the development kit includes an application programming interface known as the Java Native Interface, or JNI. As named, JNI provides a mechanism for interfacing between native software programs and newly developed Java-based bytecode.
The JNI allows code that runs inside a Java virtual machine (bytecode) to inter-operate with applications written in other high-level programming languages. Developers who program through the JNI enable native code to interact with Java code, including: creating, viewing, and updating Java objects, calling Java methods, loading and obtaining class information, handling exceptions, and the like.
Despite its best intentions, JNI may be inadequate in some environments. For example, the Win32 application programming interface, or API, permits application developers to maintain different windows, or dialogs, in a graphical user interface, or GUI. As is further developed, below, the mechanism provided by JNI for interaction between native code and Java-based code is inadequate. For one thing, the Java-based dialog is visually distinct, making its appearance on a user interface with other native dialogs look out-of-place. Second, calls to methods through the JNI causes the native code to block. This blocking nature of JNI causes a stoppage of message handling in the native dialogs, thus making the application appear to be locked up or non-responsive. Third, the native code is limited in its ability to manipulate a Java-based dialog under the JNI specification. For example, the native code cannot control any of the Java-based dialogs that it created.
The choices for resolving the limitations imposed by the JNI are very unattractive. First, the developers could completely rewrite the existing native code in Java, eliminating the need to use the JNI at all. Such an approach is generally not feasible because of the large amount of code that must be rewritten. Second, a development team could restrict all Java coding to non-GUI elements. Under such a limited environment, JNI would be sufficient. However, GUIs are a large part of most applications, requiring developers to maintain multiple versions of user interface code for each platform supported. Furthermore, if the native code is never phased out, the high level of portability that makes Java-based development attractive remains elusive.
Ultimately, these unattractive choices severely restrict the benefits of JNI and effectively divert developers from adding new features to native applications using Java.
Briefly, the illustrative system provides a method for adding functionality to a user interface of non-Java based, or native, applications, using the Java programming language. Further, the illustrative system provides a method for Java-based and non-Java-based windows, or dialogs, to communicate in an application program on a graphical user interface.
To add functionality to the user interface of the native application, new dialog support is written in the Java programming language. Under the standard protocol, a call to the Java Native Interface (JNI) blocks and waits for the function call to complete, then accepts a return value. In the system illustrated herein, however, the JNI calls do block, as normal, but, once a Java thread is created, control immediately returns to a separate thread where the native application can run. Following the creation of the Java thread, message passing between the thread and the native application is implemented, to xe2x80x9cregisterxe2x80x9d the Java dialog with the native application.
Following the registration, the Java-based dialog performs its intended function as a thread separate from the native code. When the native code receives the information for registering the Java dialog, it determines the handle of the Java dialog and then creates its own xe2x80x9cinvisiblexe2x80x9d dialog. The invisible dialog is subsequently used for all message passing to the Java dialog.
The result is a very seamless integration on a graphical user interface between the Java-based code and the native code. From the perspective of the user, the interface operates and visually appears as if controlled from a single source of code. In one embodiment, a native icon is displayed on the Java dialog, rather than a generic Java icon, so that the Java dialog xe2x80x9cmatchesxe2x80x9d the native dialogs in appearance.
Further, the registration between the Java-based code and the native code enables the native code to perform additional tasks upon the Java dialog. In addition to providing a Java-based icon similar to a native icon, the native code can detect the presence of the Java dialog or tell the Java dialog to close or move to a certain position on the screen, features which were not possible using the standard JNI protocol. In another embodiment, the native code can further capture the Java dialog into a multi-document interface, or MDI, framework, so that the Java dialog is virtually indistinguishable from the native dialogs in the application. Thus, the illustrative system provides tight Java and native window-level integration that gives the Java dialogs a similar xe2x80x9clook and feelxe2x80x9d to the native dialogs.
The illustrative system can particularly be used when augmenting a native code-based application with Java. Using the techniques described herein, a xe2x80x9cbridgexe2x80x9d between new Java code and an existing native code is provided. This gives the graphical user interface (GUI) a consistent xe2x80x9clook and feel,xe2x80x9d even though different technologies are used to develop the various GUI components.